测试内容

主要是两个方面：基础项 和 业务项

基础项：反编译、四大组件安全、信息泄漏等（这里只列举了我认为重要的，其他的比如键盘劫持、安全策略等不在范围内）

业务项：常规的WEB测试

工具列表

基础项

客户端程序安全测试

安装包签名

检测客户端是否经过正确签名（正常情况下应用都应该是签名的，否则无法安装），通过签名，可以检测出安装包在签名后是否被修改过。

• 方式一

    keytool -printcert -jarfile sieve.apk
  

  

• 方式二

    jarsigner -verify -certs -verbose sieve.apk
  

  

• 方式三

  通过mobsf扫描结果查看

  

注意：只有在使用直接客户的证书签名时，才认为安全。 Debug 证书、第三方（如开发方）证书等等均认为风险。

客户端程序保护

测试客户端安装程序，判断是否能反编译为源代码，是否存在代码混淆等保护措施。未作保护的java代码，可以轻易分析其运行逻辑，并针对代码中的缺陷对客户端或服务器端进行攻击。

将APK直接拖到jadx中进行分析，如下图所示

如果代码经过混淆，或者有加壳措施，不能完整恢复源代码的，可以认为此项安全，混淆后的代码样例，除了覆写和接口以外的字段都是无意义的名称。

应用完整性校检

测试客户端程序是否对自身完整性进行校验。攻击者能够通过反编译的方法在客户端程序中植入自己的木马，客户端程序如果没有自校验机制的话，攻击者可能会通过篡改客户端程序窃取手机用户的隐私信息。

检测步骤如下：

1. 使用apktool对APK进行解包

    # apktool d -f <APK文件> -o <解包目录>
    apktool d -f sieve.apk -o test
   

2. 解包后随便修改一个资源文件，建议APP名、logo、版本号等资源文件，比较方便确认结果。

   

3. 修改后使用apktool重新打包为apk

    # apktool b -f <解包目录> -o <xxx.apk>
    apktool b -f test -o sieve_new.apk
   

4. 对生成的APK进行签名

    # 生成应用证书
    keytool -genkey -alias myalias -keyalg RSA -keystore mykey.keystore
    # 签名
    jarsigner -verbose -keystore mykey.keystore sieve_new.apk myalias
   

5. 覆盖安装到设备中并打开，查看能否启动以及刚才修改的内容是否生效

    adb install -r sieve_new.apk
   

Debug模式

客户端软件 AndroidManifest.xml 中的 android:debuggable="true"标记如果开启，可被Java 调试工具例如 jdb 进行调试，获取和篡改用户敏感信息，甚至分析并且修改代码实现的业务逻辑，我们经常使用 android.util.Log 来打印日志，软件发布后调试日志被其他开发者看到，容易被反编译破解。

可以通过jadx、mobsf、apktool中获取到AndroidManifest.xml文件，查看文件内容即可，下图为jadx获取到的该文件。

应用程序数据可备份

Android 2.1 以上的系统可为 App 提供应用程序数据的备份和恢复功能，该由AndroidMainfest.xml 文件中的 allowBackup 属性值控制，其默认值为 true。当该属性没有显式设置为 false 时,攻击者可通过 adb backup 和 adb restore 对 App 的应用数据进行备份和恢复，从而可能获取明文存储的用户敏感信息。

组件安全测试

Activity

Activity 是实现应用程序的主体，它承担了大量的显示和交互工作，甚至可以理解为一个“界面”就是一个 Activity。

测试参考《drozer测试四大组件 Activity》

Service

一个 Service 是没有界面且能长时间运行于后台的应用组件．其它应用的组件可以启动一个服务运行于后台，即使用户切换到另一个应用也会继续运行．另外，一个组件可以绑定到一个 service 来进行交互，即使这个交互是进程间通讯也没问题．例如，一个 service 可能处理网络事物，播放音乐，执行文件 I/O，或与一个内容提供者交互，所有这些都在后台进行

测试参考《drozer测试四大组件 Service》

Content Provider

Android Content Provider 存在文件目录遍历安全漏洞，该漏洞源于对外暴露 Content Provider 组件的应用，没有对 Content Provider 组件的访问进行权限控制和对访问的目标文件的 Content Query Uri 进行有效判断，攻击者利用该应用暴露的 Content Provider的 openFile()接口进行文件目录遍历以达到访问任意可读文件的目的。在使用 Content Provider 时，将组件导出，提供了 query 接口。由于 query 接口传入的参数直接或间接由接口调用者传入，攻击者构造 sql injection 语句，造成信息的泄漏甚至是应用私有数据的恶意改写和删除。

测试参考《drozer测试四大组件 Content Provider》

Broadcast Reciever

Broadcast Recevier 广播接收器是一个专注于接收广播通知信息，并做出对应处理的组件。很多广播是源自于系统代码的──比如，通知时区改变、电池电量低、拍摄了一张照片或者用户改变了语言选项。应用程序也可以进行广播──比如说，通知其它应用程序一些数据下载完成并处于可用状态。应用程序可以拥有任意数量的广播接收器以对所有它感兴趣的通知信息予以响应。所有的接收器均继承自 BroadcastReceiver 基类。广播接收器没有用户界面。然而，它们可以启动一个 activity 来响应它们收到的信息，或者用 NotificationManager来通知用户。通知可以用很多种方式来吸引用户的注意力──闪动背灯、震动、播放声音等等。一般来说是在状态栏上放一个持久的图标，用户可以打开它并获取消息。

测试参考《drozer测试四大组件 Broadcast Reciever》

WebView 代码执行检测

android系统通过WebView.addJavascriptInterface方法注册可供JavaScript调用的Java对象，以用于增强 JavaScript 的功能。但是系统并没有对注册 Java 类的方法调用的限制。导致攻击者可以利用反射机制调用未注册的其它任何 Java 类，最终导致 JavaScript 能力的无限增强。攻击者利用该漏洞可以根据客户端执行任意代码。

Webview 代 码 执 行 漏 洞 出 现 在 安 卓 2.1~4.3.1 版 本 ， 检 查 targetSdkVersion，若 targetsdkVersion>=19 或通过 minSdkVersion 进行限制则无此问题，否则在低版本上测试，检查代码中是否使用 addJavascriptInterface()。

检查targetSdkVersion

检查代码是否使用addJavascriptInterface()

WebView 不校验证书检测

调用了 android/webkit/SslErrorHandler 类的 proceed 方法,可能导致 WebView 忽略校验证书的步骤。在代码中搜索onReceivedSslError，看是否调用了 handle.process() 方法

WebView 密码明文保存检测

在使用 WebView 的过程中忽略了 WebView setSavePassword，当用户选择保存在WebView 中输入的用户名和密码，则会被明文保存到应用数据目录的databases/webview.db中。如果手机被 root就可以获取明文保存的密码，造成用户的个人敏感数据泄露

在代码中搜索setSavePassword，看是否显式设置为 false

敏感信息安全测试

检查客户端程序 apk 包中是否保存有敏感信息

有些时候，客户端程序 apk 包中会保存有敏感信息，如账号密码、IP地址、邮箱等，可通过检查 apk 包中源代码和资源文件来判定。

也可通过MOBSF的扫描结果进行分析。

检查私有目录下的文件权限

对 android 的每一个应用，android 系统会分配一个私有目录，用于存储应用的私有数据。此私有目录通常位于/data/data/应用名称/。

在测试时，建议完全退出客户端后，再进行私有文件的测试，以确保测试结果的准确性（有些客户端在退出时会清理临时文件）。

检查文件和文件夹的权限，正常的文件权限最后三位应为空（如rw-rw---- ），即除应用自己以外任何人无法读写； 目录则允许多一个执行位（如rwxrwx--x ）。

lib 子目录是应用安装时由 android 系统自动生成，所以权限很高，一般是777，这个不用管。

adb shell
su
cd /data/data/com.mwr.example.sieve
ls -la

检查私有目录下的信息泄漏

查看私有目录/data/data/应用名称/下的文件如xml文件、sqlite数据库文件是否包含敏感信息。

检查日志是否打印敏感数据

调试日志函数可能输出重要的日志文件，其中包含的信息可能导致客户端用户信息泄露，暴露客户端代码逻辑等，为发起攻击提供便利。

使用如下命令实时打印日志：

adb logcat

操作APP，观察是否有敏感记录输出

进程安全测试

内存访问和修改

通过对客户端内存的访问，木马将有可能会得到保存在内存中的敏感信息（如登录密码，帐号等）。测试客户端内存中是否存在的敏感信息（卡号、明文密码等等）。

可通过frida + objection来实现内存搜索和修改，参考objection教程

动态注入防护检测

测试客户端是否对自身进程进行保护，防止其他应用访问进程内存中的敏感信息。

可通过frida进行hook关键函数，如加解密、转账等，参考frida教程

本地端口开放检测

通常使用 PF_UNIX、PF_INET、PF_NETLINK 等不同 domain 的 socket 来进行本地 IPC 或者远程网络通信，这些暴露的 socket 代表了潜在的本地或远程攻击面，历史上也出现过不少利用 socket 进行拒绝服务、root 提权或者远程命令执行的案例。特别是 PF_INET 类型的网络 socket，可以通过网络与 Android 应用通信，其原本用于 linux 环境下开放网络服务，由于缺乏对网络调用者身份或者本地调用者 id、permission 等细粒度的安全检查机制，在实现不当的情况下，可以突破 Android 的沙箱限制，以被攻击应用的权限执行命令，通常出现比较严重的漏洞。

netstat -antup | grep -Ei 'listen|udp'

外部动态加载 DEX 安全风险检测

Android 系统提供了一种类加载器 DexClassLoader，其可以在运行时动态加载并解释执行包含在 JAR 或 APK 文件内的 DEX 文件。外部动态加载 DEX 文件的安全风险源于：Anroid4.1 之前的系统版本容许 Android 应用将动态加载的 DEX 文件存储在被其他应用任意读写的目录中(如 sdcard)，因此不能够保护应用免遭恶意代码的注入；所加载的 DEX 易被恶意应用所替换或者代码注入，如果没有对外部所加载的 DEX 文件做完整性校验，应用将会被恶意代码注入，从而执行的是恶意代码。

在代码中搜索DexClassLoader，查看是否存在相关代码。

业务项

1. 可以通读一遍MOBSF扫描的结果，看看哪些资源是自己需要的，比如提取URL功能就很实用。
2. 再通过代理的方式，正常抓包改包，测试常见的安全漏洞即可，可参考：WEB常见漏洞
3. 最后可以看看哪些Activity是没有测到的，然后去对应的Activity页面看看有没有没有测到的功能。